|
|
|
|
|
|
|
Figure 3.4.
This is how your sequence diagram would appear as a collaboration diagram. |
|
|
|
|
|
|
|
|
Dividing a Proposed Visual Basic Application into Subsystem Packages |
|
|
|
|
|
|
|
|
As if the concept of classes and objects weren't difficult enough, you must also become familiar with the idea of dividing your applications into logical subapplications or subsystems. A subsystem is composed of one to many classes whose object instances interact with each other to carry out a common application behavior. Groupings of classes are also called packages. To give you an example, you will have a subsystem that handles communications between the data repository (database, flat file, and so on) and the application. There's no sense in every form needing to communicate directly with the data repository, which has become the norm in the Visual Basic development community. This flattens the system architecture, graying the lines between the User, Business, and Data Services layers, and thus can cause spaghetti code. What's more, code reuse is next to impossible to hope for when all the layers of the application code are embedded within forms. Delegating key functionality to subsystems not only helps avoid spaghetti code but also greatly increases the readability of the code and the ability to assign parts of the application to each member of a team of developers. |
|
|
|
|
|
